Web servers are commonly used to provide users, generally using a client computer, with information, and optionally to receive input from users. One protocol used for transmitting data between clients and Web servers is the HTTP (Hypertext transfer protocol) protocol. In the HTTP protocol, the client transmits to the server a request message that generally includes a uniform resource locator (URL) which indicates the file (or any other object) to which the request message pertains. The request message may be included in one or more packets, the first of which usually includes the URL. Responsive to the request message, the server transmits to the client a result message which includes the response of the server to the request.
The HTTP protocol generally operates over a transport protocol, e.g., TCP, which provides a connection between the client computer and the server.
In many cases, for example when providing credit card information, it is desired that the information transmitted between the client and server be encrypted to prevent eavesdroppers from extracting tangible information from the transmitted messages. One common encryption protocol is the secure sockets layer (SSL) protocol which mediates between application protocols (e.g., HTTP, FTP) and a transport protocol (e.g., TCP). Generally, when an SSL session is established, the client and server perform a negotiation phase, in which the client and server authenticate each other and negotiate an encryption algorithm and cryptographic keys. Data is transmitted in the SSL session between the server and client only after successful completion of the negotiation phase.
The negotiation phase of the SSL protocol is generally initiated by the client, which transmits an SSL “client hello” message to the server. During the negotiation phase, the server assigns the session an SSL session ID, which represents the SSL session.
The SSL protocol also defines a fast connection establishment process, which skips various security verification steps of the negotiation phase. In order to allow the fast connection establishment process, the server stores the SSL session ID assigned to negotiated sessions along with other information relating to the session, for a predetermined time after the termination of the session. If a client desires to establish an SSL connection based on an existing SSL ID, the client transmits an SSL “client hello” message to the server with the SSL session ID. A new SSL session is established by the client transmitting a “client hello” message which does not include a session ID value, for example states a zero field length in a session ID field. The ability to establish SSL connections, using the fast connection establishment process, is referred to herein as SSL persistency.
In versions 1 and 3 of the SSL protocol, the signals of the SSL negotiation phase are not encrypted and can be understood by intermediate units capturing the transmitted messages of the negotiation phase. The transmitted data, however, is encrypted and cannot be understood by intervening units.
Many Web sites are hosted by a plurality of servers, because of the large number of clients accessing the Web site, the large volume of the information carried by the Web site and/or for redundancy purposes. A load balancer receives the packets directed to the Web site and forwards them to a respective server based on one or more parameters. Load balancers are also used for other purposes, for example, for redirecting HTTP requests to a proxy cache.
If the advantage of SSL persistency is to be exploited, the load balancer should forward “client hello” messages belonging to a single client to the same server, as a different server will not necessarily have the information required for the SSL persistency of the client. One method used by load balancers to ensure that packets from a single client are forwarded to the same server is tracking the SSL session IDs of sessions handled by the load balancer. For each SSL session, the load balancer lists the session ID of the session and the address of the server to which the packets of the session were forwarded.
The storage space required for listing the SSL session IDs may be very large, substantially adding to the cost of the load balancer. In addition, the performance of the load balancer is degraded due to the need to search large lists of SSL session IDs or to manage sorted lists. Reducing the size of the SSL ID list would limit the effectiveness of SSL persistency. Furthermore, in some cases, the session ID of a session is changed during the encrypted session, and the load balancer is not aware of the change. In such cases, the load balancer will not find an entry in its list matching the session ID and the SSL persistency will be lost.